[포스코x코딩온] 웹 풀스택 과정 7기 7주차 금요일 회고

포맷터 통일

팀 프로젝트를 진행하는데, 팀원들끼리 포맷터 설정이 제각각이라 커밋마다 쓸데없는 변경사항이 수도 없이 생겨났다.

- import { Request, Response } from 'express';
+ import { Request, Response } from "express";
- import { Controller } from '@/types';
+ import { Controller } from "@/types";
 
- import login from './login';
- import signup from './signup';
- import todo from './todo';
+ import login from "./login";
+ import signup from "./signup";
+ import todo from "./todo";
 
-declare module 'express-session' {
-    interface SessionData {
-        user: number;
-    }
+ declare module "express-session" {
+   interface SessionData {
+     user: number;
+   }
}

보기만 해도 혈압이 오른다. :rage:
팀원들이 모두 VSCode를 사용했기 때문에, .vscode/settings.json 파일을 통해 포맷터 설정을 통일했다.

테스트 생성

Jest를 사용해 테스트를 생성했다.
간단히 API를 통해 데이터를 보내고 DB에 저장되는지 확인하는 테스트를 작성했다.
예를 들어 DIARY 객체를 생성하는 API 테스트 코드는 다음과 같이 작성하였다.

test("create diary", async () => {
  const [id, pw] = genIdPw();
  await signup(id, pw, app);
  const loginRes = await login(id, pw, app);
  const cookie = loginRes.header["set-cookie"];
  const [year, month, date] = dateSeparate(new Date());
  const [title, content] = genIdPw();
  const res = await request(app)
    .post(`/diary/${year}/${month}/${date}`)
    .set("Cookie", cookie)
    .send({
      title,
      content,
      emotion: "1",
    });
  const result = res.body as Diary;
  expect(result?.title).toBe(title);
  const userResult = await db.user.findOne({
    where: {
      username: id,
    },
  });
  const user = userResult?.toJSON<User>();
  const diaryResult = await db.diary.findOne({
    where: {
      user_id: user?.id,
      year,
      month,
      date,
    },
  });
  const diary = diaryResult?.toJSON<Diary>();
  expect(diary?.title).toBe(title);
});

테스트 코드를 작성하니 예상도 못하고 있던 오류들이 온갖 곳에서 튀어나왔다.
물론 테스트 코드 자체가 잘못된 경우도 종종 있었지만, 대부분은 프로덕트 코드에 오류가 있었다.
테스트 코드를 작성하면서 오류를 수정하고, 오류를 수정하면서 테스트 코드를 작성하는 과정을 반복하며 코드를 수정했다.
덕분에 코드의 품질이 훨씬 개선됐다.
왜 다들 TDD(Test Driven Development)를 추천하는지 알 것 같다.

PR 리뷰

프로젝트가 서서히 완성되어 가면서, 프로젝트를 직접 만들기 보다는 팀원들의 PR을 review하는 시간이 더 많아졌다.
코드를 읽고 이해하고 피드백을 주는 과정이 생각보다 어렵고 오래 걸리는 작업이었다.
비록 많은 코드를 작성하지는 못했지만, 다른 사람의 코드를 이해하는 능력과 피드백을 주고 새로운 작업 사항을 지시하는 능력이 많이 향상된 것 같다.

Git에 대한 고찰

팀원들과 함께 작업을 하면서 여러 끔찍한 케이스를 겪었다.

Conflict
정말 수도 없이 겪었다...
커밋이고 푸시고 PR이고 올리기 전에 dev 브랜치에서 먼저 merge 하고 올려달라고 신신당부를 했건만, 왜 매번 컨플릭트가 나는 걸까ㅠㅠ

정말 다들 저한테 왜 그러시는 거죠???
PR 혹은 커밋 메세지에 본인 이름 적기/하루치 변경 사항 커밋 하나에 넣기
본인이 한 작업은 본인의 자취를 남기고 싶은 마음은 충분히 이해한다.
그치만... 본인 이름만 띡 적어내시면... 제가 여러분이 뭘 했는지 어떻게 아나요...
게다가... 하루치 수정 사항을 커밋 하나에 다 담아서 넣어놓고 날짜를 적어두시면...
어차피 커밋에 본인 깃헙 계정이랑 날짜 시간 다 적혀서 나와요...
그니까 제발... <본인 이름> <날짜> 수정사항 이런 식의 커밋 메세지는 그만둬 주시길 간곡히 부탁드리옵니다...
스스로 본인 PR 승인하기
...
심지어 10분 후에 집 갈 시간이었는데...
진짜 울 뻔 했다.
다행히 GitHub에서 직전의 PR을 바로 Revert 할 수 있는 기능이 있어 실행했다.
그리고 바로 모든 팀원들을 Contributor에서 제외시켰다.
그 다음날 해당 PR 브랜치를 가져와 수정하고 다시 PR을 올리고 merge했다.
팀원이라고 무작정 Contributor로 등록해 권한을 주기보단, 특히 Git에 대한 이해가 부족한 팀원을 위해서라도, repository를 fork해서 작업하도록 지시하는 것이 더 안전하다는 것을 뼈저리게 느꼈다.

Git이 단순히 코드 백업용이 아니라, 협업툴 이라는 것을 다들 인지하고 팀과의 협업을 위해 사용해주셨으면 좋겠다.

Chomu's Blog.

Posts

[포스코x코딩온] 웹 풀스택 과정 7기 7주차 금요일 회고

목차

포맷터 통일

테스트 생성

PR 리뷰

Git에 대한 고찰